In modern computing systems, it has become commonplace to expand their use to a wide variety of environments with diversely differing applications and protocols. As an example, systems are being required to support both media and communications applications and protocols such as fiber channel subsystems supporting IPI-3 and SCSI or TCP/IP, respectively.
While the role of the computer is expanding to meet these ever-increasing needs, there are nevertheless severe constraints continuously being imposed on the industry. Users, while requiring increased versatility and functionality, nevertheless are simultaneously now demanding that it be delivered at lower and lower costs.
As a representative example of the problems this can cause, in some applications it is necessary to provide a single adapter which may support both media and communication applications. This is but one illustration of the operation of these cost constraints wherein it is simply not feasible to provide separate adapters for media, communications, and other applications. Rather there is a need to provide a single multi-purpose adapter which may support these differing applications and their associated protocols. Nevertheless, there are severe problems associated with providing a single device driver interface for a single adapter which could support two or more drastically different application and protocol types such as media and communications.
In passing, it will be helpful in order to understand the importance of the invention in dealing with multiple protocols and the problems associated with the wide variances and characteristics of such protocols, to briefly highlight the differences between, example, media and communication protocols.
Media protocols typically involved transmitting data having the same block and link size wherein writes and reads are encountered, e.g. a write command may be transmitted and a fixed amount of data be expected in return. In contrast, communication protocols typically have the characteristic that data will be received in unknown quantities and in unknown times unsolicited e.g. asynchronously. Although the implementation herein described has been with respect to the different protocols being a media and communication protocol with associated BUF and MBUF structures the invention is not intended to be so limited. The invention admits to application of multiple protocols utilizing different structures in their interfaces which have the aforementioned three common links, namely a pointer to data, the length of the data, and the cross/memory descriptor for setting up DMA. Accordingly any protocol using different structure in the path may also be advantageously combined to communicate with the same driver in accordance with the teaching of the invention utilizing the different structures so long as the three elements are present therein.
In a more generic sense, the media and the communication and protocols may be seen to be distinguished by whether asynchronous or synchronous data is handled and whether it is fixed or variable data block size. The different protocols arise from the need to provide different structures to efficiently control management of data having these variable characteristics, thereby giving rise to media protocols employing the BUF structures and communication protocols employing MBUF structures.
A conventional approach to such a problem of supporting multiple protocols was to provide for a single data structure and to copy data between software layers. However, as is well known in the art, a key to successful high-performance interfaces, (as is required in media and communication applications, for example,) is to do just the opposite, namely to avoid copying data between software layers.
An alternate approach taken in the prior art to avoid the performance penalty associated with recopying of data was to provide a different architecture wherein device drivers did not exist in the kernel. An example of this was the System Control Block (SCB) Architecture. Data was provided in SCB format and passed down in the manner to be described shown in FIG. 2 as their interfaces. The approach taken in such a system was to rewrite the protocol stack code to work on a single device driver. Not only did this approach suffer the serious drawback of requiring reimplementation of substantial portions of code, but their performance hits were nevertheless even still encountered resulting from instances of copying of data.
Although attempts have been made to provide in some platforms for a common device driver interface structure for media and communication protocols for example (such as that provided by SCB for use with PS/2 Computers produced by the IBM Corporation), in other environments the problem has not yet even been addressed at all. Thus, no common device driver interface structure for multiple protocols such as media and communication even exist presently for UNIX-Based Systems.
From the foregoing, it is readily apparent that a system and method was desired for effecting a multiple protocol device interface subsystem wherein the necessity to copy data between software layers was avoided.
It was yet another object of the invention to provide a subsystem which could be utilized with a single adapter in an environment running media and application programs which was cost effective and easy to implement.
Still a further object of the invention was to provide for a device driver subsystem interface which could be used in a multi-protocol environment wherein pre-existing core structures could be utilized, obviating the need to rewrite device driver code to new structures.
Yet a further object was to provide such a multi-purpose interface which yielded high performance otherwise difficult to obtain with conventional data copying techniques.
These and other objects are achieved by the subject invention, a more detailed description of which may be obtained with reference to the following figures wherein: